-
Notifications
You must be signed in to change notification settings - Fork 8
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Drop fd acking in sidecar transport #481
Conversation
This has effectively been never working - it probably got added in long times past, before unidirectional sending was added. There's no ack, and thus it would simply leak and stay unclosed forever. Signed-off-by: Bob Weinand <bob.weinand@datadoghq.com>
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #481 +/- ##
==========================================
- Coverage 69.18% 69.17% -0.01%
==========================================
Files 195 195
Lines 26144 26109 -35
==========================================
- Hits 18087 18061 -26
+ Misses 8057 8048 -9
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can only repeat that it would have been nice with some comments trying to explain the whole machinery in here.
As for removing this ack thing, what does that mean for the rest of the convoluted code in PlatformHandle
, and how do we test that properly?
I haven't written that code, but the primary issue is that, if a write couldn't be sent through (if buffer full), we'll have to retry the write. The rust async writes machinery will retry the write with a given buf then. But it doesn't have any idea of the adjacent file descriptions sent. So we'll have to store these separately and try sending them again when possible. Also, we rely on in-order message delivery. So, we'll just buffer file descriptions until we know they were sent. (and may send file descriptions before the message they're actually attached to) The receiver side will then just pop handles as soon as a message expecting a file description is received. |
This has effectively been never working - it probably got added in long times past, before unidirectional sending was added. There's no ack, and thus it would simply leak and stay unclosed forever.
And the functionality is simply not needed. It's not like linux would close file descriptions as long as they're referenced in sendmsg buffers.